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Abstract. We present an effect system for core Eff , , a simplified variant of Eff, which is 
an ML-style programming language with first-class algebraic effects and handlers. We de- 
fine an expressive effect system and prove safety of operational semantics with respect to it. 
Then we give a domain-theoretic denotational semantics of core Eff, using Pitts’s theory 
of minimal invariant relations, and prove it adequate. We use this fact to develop tools for 
finding useful contextual equivalences, including an induction principle. To demonstrate 
their usefulness, we use these tools to derive the usual equations for mutable state, includ- 
ing a general commutativity law for computations using non-interfering references. We 
have formalized the effect system, the operational semantics, and the safety theorem in 
Twelf. 


1. Introduction 

An effect system supplements a traditional type system for a programming language with 
information about which computational effects may, will, or will not happen when a piece of 
code is executed. A well designed and solidly implemented effect system helps programmers 
understand source code, find mistakes, as well as safely rearrange, optimize, and parallelize 
code mm- As many before us mmmm we take on the task of striking just the right 
balance between simplicity and expressiveness by devising an effect system for Eff [2], an 
ML-style programming language with first-class algebraic effects mm and handlers m- 
Our effect system is descriptive in the sense that it provides information about possible 
computational effects but it does not prescribe them. In contrast, Haskell’s monads prescribe 
the possible effects by wrapping types into computational monads. In the implementation 
we envision effect inference which never fails, although in some cases it may be uninformative. 
Of course, typing errors are still errors. 

An important feature of our effect system is non-monotonicity: it detects the fact that 
a handler removes some effects. For instance, a piece of code which uses mutable state is 
determined to actually be pure when wrapped by a handler that handles away lookups and 
updates. 

2012 ACM CCS: [Software and its engineering]: Software notations and tools — General programming 
languages — Language features; [Theory of computation]: Semantics and reasoning. 
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* A preliminary version of this work was presented at CALCO 2013, see [3]. 
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Our contributions are as follows: 

(1) We define core Eff, a fragment of the language which retains the essential features of Eff , 
including first-class handlers and instances (Section [2]), although we leave out dynamic 
creation of new instances. 

(2) We give small-step and big-step operational semantics for core Eff and show them to 
be equivalent (Section 02). 

(3) We devise an expressive effect system for core Eff and prove safety of the operational 
semantics with respect to it (Section 0]). 

(4) Using the standard domain-theoretic apparatus and Pitts’s theory of minimal invariant 
relations M, we provide denotational semantics for core Eff and prove an adequacy 
theorem (Section [5]). 

(5) We identify a set of observational equivalences and an induction principle that allow us 
to reason about effectful computations (Section [6]). 

(6) We demonstrate how the equivalences are used by deriving the standard equations for 
state from general principles. The induction principle is used in a proof of a general com- 
mutativity law which allows us to interchange two computations that use non-interfering 
references (Section [7]). 

(7) We formalized core Eff , the operational semantics, the effect system, and the safety 
theorem in Twelf [T3j (Section [8]). 


2. Core Eff 

The current implementation of Eff includes a number of features, such as syntactic sugar, 
products, records, inductive types, type definitions, effect definitions, etc., which are inessen- 
tial for a conceptual analysis. We therefore restrict attention to core Eff, a fragment of the 
language described here. We refer the readers to [2] for a more thorough introduction of 
how one actually programs in Eff. 

In Eff all computational effects are accessed uniformly and exclusively through opera- 
tions. These are a primitive concept, of which typical examples are reading and writing on 
a communication channel, updating and looking up the contents of a reference, and raising 
an exception. Thus, in Eff each terminating computation results either in an effect-free 
value, or it calls an operation. Each operation has an associated delimited continuation, 
which is a suspended computation awaiting the result of the operation. 

Operations do not actually perform effects, but are just suspended computations whose 
behavior is controlled by a second primitive notion, the effect handlers. These are like 
exception handlers, except that an effect handler has access to the continuation of the 
handled operation, and so may restart the computation after the operation is handled. With 
handlers we may implement all the usual computational effects, as well as great variety 
of others, such as transactional memory, non-deterministic execution strategies, stream 
redirection, cooperative multi-threading, and delimited continuations. At the top level there 
may be built-in handlers that provide interaction with the external environment, although 
we do not consider these in core Eff. 

Since Eff is geared towards practical programming, it and core Eff depart in several 
respects from previous work on handlers and algebraic effects mm- First, rather than 
imposing equations on handlers by a typing discipline, the programmer may write arbitrary 
handlers, and then prove that a particular handler satisfies the desired equations. We 
demonstrate the technique in Section l7Tl where we implement a state handler and show that 
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it satisfies the standard equations. Second, Eff uses fine-grained call- by- value evaluation 
strategy m rather than the theoretically more desirable call-by-push-value [9j because 
we found the former to be closer to programming practice as well as easier to implement. 
Third, every effect has multiple instances. For example, a program may write and read 
from multiple communication channels, raise different kinds of exceptions, and manipulate 
multipartite state. Thus in core Eff an operation symbol op is always paired with an instance 
l to give an operation i# op. From a theoretical point of view instances are straightforward (as 
long as we do not generate them dynamically) and inessential, but are absolutely necessary 
for practical programming. 

2.1. Effects and types. To get things going we presume given a collection of effects 

Effect E ::= exception | ref | ••• 

which in full Eff are declared by the programmer. For each E there is a given set Te of 
instances l±, l- 2 , l- 3 , . . . of E. The instances may be thought of as atomic names. In full 
Eff they may be dynamically created, but to keep the semantics reasonably simple we 
assume a fixed set. Additionally, with each E we associate a set of Oe of operation symbols 
op 1 , op 2 , . . . An operation symbol is associated with at most one effect. 

The terms of core Eff are split into effect-free expressions and possibly effectful com- 
putations, as described in the next subsection. Consequently, the type system of core Eff 
consists of pure types for expressions and dirty types for computations: 

Pure type A, I? ::= bool | nat | unit | empty | A — > C_ | E R | (7 => D_ 

Dirty type (7, D_ : : = A ! A 

Region R ::= {ti, ... ,t n } 

Dirt A ::= {ii#op 1 , . . . , t n #op n } 

A dirty type A ! A is just a pure type A tagged with a finite set A of operations that might be 
called during evaluation. We require that any operation l# op appearing in A is well-formed 
in the sense that l G Te and op £ Oe for some effect E. 

The pure types comprise the usual ground types, the function types A — > (7, the effect 
types E r , and the handler types C =>- Iff. Note that the function type takes pure types 
to dirty ones because a function accepts a pure expression as an argument and may call 
operations when evaluated. We let ! bind more strongly than — >, so that A — > B ! A means 
A — > (B ! A). Each effect type E r is tagged with a finite set of instances R = {l i, ■ ■ ■ , i n } C 
Te which tells us that the expression equals one of the instances in R. Finally, (7 =k D is the 
type of handlers which take computations of ingoing type (7 to computations of outgoing 
type D. 

We assume that each effect E has an associated effect signature 

Z E = {o Pl : A° Pl -A R op S . . . , op n : A op - -A R op ™} 

which assigns to each operation op^ G Oe its parameter type A° Pi and result type B° Pi . In 
full Eff the signature is part of the definition of an effect, so for instance we might have 

E ref = {lookup : unit —> nat, update : nat — > unit}, 

^exception = {raise : unit -A- empty}. 
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Note that the signature may create circularities such as 

He = {op : unit — > (unit -A unit ! {i#op})}. 

Consequently, the denotational semantics of types in Section [5] will involve recursive domain 
equations. 

2.2. Terms. The abstract syntax of terms of core Eff is as follows: 

Expression e ::= x | true | false | 0 | succ e | () | fun x : A H >■ c | t | h 
Handler h ::= (handler val x : A H >• c v \ ocs ) 

Operation cases ocs ::= nilc \ ( e#opxk i-A c | ocs) 

Computation c ::= val e | ei#ope 2 (y.c) | with e handle c | 
if e then c\ else C 2 | absurd^ e | ei e 2 | 

(match e with 0 i— > c\ | succ x i-A C 2 ) | 

let x = ci in C2 | let rec f x : A -A C_ = ci in C2 

In order to ensure that each term has at most one skeletal typing derivation, cf. Subsec- 
tion 14.31 certain terms include typing annotations. We shall omit these when they do not 
play a role. The Eff implementation does not have typing annotations because its effect 
system automatically infers types and effects || 22| . 

An expression is either a variable, a constant of ground type, a function abstraction 
(note that we abstract over computations), an effect instance, or a handler. It is worth 
noting that both instances and handlers are first-class values. We sometimes abbreviate 
succ n 0 as n. A handler consists of a single value case and multiple operation cases, which 
describe how values and operations are handled, respectively. We defined operation cases 
inductively as lists, which is how they are formalized in Twelf, but we also write them as 
(ej#opj Xi ki i-A cfn . 

A computation is either a pure expression, an operation call, a handle construct, an 
eliminator for a ground type, an application, a let binding, or a recursive function definition. 

3. Operational semantics 

We first describe the operational semantics informally. A computation val e is pure and 
indicates a “final” result e, while an operation call ei#ope 2 (y.c) is the principal way of 
triggering an effect. The instance ei and the operation symbol op together form an oper- 
ation ei#op, its parameter is e 2 , and ( y.c ) the delimited continuation. We do not expect 
programmers to write explicit continuations, so the concrete syntax of Eff only gives access 
to calls through functions of the form fun x i-a e#opx(y.val y ), known also as generic 
effects m- In examples we shall use generic effects rather than explicit continuations, and 
there we write them as e#op. A general operation call ei#ope 2 ( y ■ c ) may then be expressed 
in terms of a generic effect and a let binding as let y = ei#ope 2 in c. 

A binding let x = ci in C 2 is evaluated as follows: 

(1) If ci evaluates to val e then the binding evaluates as C 2 with x bound to e. 
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( 2 ) If ci evaluates to an operation call t# ope (y. c'{), then the binding evaluates to 

i#op e (y. let x = c\ in C2), 
where we assume that y does not occur free in C2. 

It may be helpful to think of val and let as being similar to Haskell return and do, 
respectively. In ML val is invisible, while let is essentially the same as ours. 

The handle construct applies a handler to a computation. If h is the handler 

handler val x 1— >• c v | (0# op^ x* ki 1— >• Cj)j 

and c is a computation, then with h handle c first evaluates c which is then handled 
according to h: 

( 1 ) If c evaluates to val e, then the handle construct evaluates as c v with x bound to e. 

( 2 ) If c evaluates to z#op e! (y. c'), and c#op - Xi k t i-a Cj is the first operation case in h for 
which l# op = ii# opj then the handle construct evaluates to c* with Xi and ki bound to 
e' and fun y 1 — > with h handle cf, respectively. We assume that y does not occur free 
in h. 

(3) If c evaluates to an operation call z#op e' (y. c 1 ) which is not listed by h , then the handle 
construct propagates the call and acts as if h contained the clause 

L#opxk i-a l# opx (y. ky). 

Thus it evaluates to /.#op e' (y. with h handle c'), where again we assume that y does 
not occur free in h. 

Note that the handler always wraps itself around the continuation so that subsequent oper- 
ations are handled as well. A binding let x = ci in C2 is equivalent to 

with (handler val x 1 — > C2) handle c\ 

so we could theoretically omit let. 

3.1. Small-step semantics. The small-step operational semantics of core Eff is defined 
in terms of a relation c c! , which intuitively means that the computation c takes a single 

step to d . There is no operational semantics for expressions, which are just inert pieces of 
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data. The relation is defined inductively by the following rules: 


if true then c\ else C2 C\ 


if false then C\ else C2 Ci 


(match 0 with 0 i — >• ci | succ x K > C2) c\ (match (succ e) with 0 1 — >- Ci | succ x i-> C2) C2\e/x\ 


Cl Ci 


(fun xi -f c)e^ c\e/x\ 


let x = Ci in C2 let x = c\ in C2 


let x = (val e) in c c\e/x\ let x = (t#op e ( y . ci)) in C2 l# op e (y. let x = Ci in C2) 


let rec f x = C\ in C2 C2[(fun x i-A let rec f x = C\ in c\)/ f] 


c d 


with e handle c with e handle c! with (handler val x i-> c v \ ocs) handle (val e) c v [e/x\ 

h = (handler val x i-» c v \ ocs) (op : A° v — > 13 op ) £ E e 
with h handle (t#ope ( y . c)) ocs L # o P (e, (fun y : B° v > with h handle c)) 

In the last rule for let binding and the last rule for the handle construct variable y must 
not occur free in C2 and h respectively, and it goes without saying that the substitutions 
are capture avoiding. In the last rule we have an auxiliary definition of ocs t # op : 

Oifh# 0 p(e, k) = t#op e (y. k y ) 


In words, ocs t # op (e, k) finds the first handler case in ocs that matches the operation l# op 
and executes it, or calls the operation again if no match is found. 

Example 3.1. The non-standard state handler (recall that in examples we use generic 
effects) 


the handled computation. This update is not handled by h because it escapes its scope. If 
we use h to handle the computation 



h = handler 


| val x 1 — y t#updatex 
| i#lookup x k 1 — > k 1 
| ;.#update x k 1— > k () 


treats the reference l as if its content were always 1, and updates t with the final result of 


c = let x\ = i#lookup O in 
let X 2 = t#update x\ in 
val (succ x\) 


the outcome of the first lookup is 1, which is bound to xi, the update is ignored and finally 
*#update2 is called. The exact reduction sequence is as follows, where we underline the 
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active parts at each step and indicate desugaring of generic effects with =: 
with h handle 

let x\ = t#lookup () in let X2 = i#updatea;i in val (succ X\) = 
with h handle 

let x\ = t#lookup()(j/i. val 2/1) in let X2 = t#updatexi in val (succ *1) 
with h handle 

;#lookupQ(yi. let X\ = val 2/1 in let X2 = /#updatea;i in val (succ £1)) -w 
(fun yi 1 — ^ with h handle (let X\ = val yi in let X2 = i#updatexi in val (succ Xi))) 1 
with h handle (let x\ = val 1 in let X2 = i#updatexi in val (succ xi)) 
with h handle (let X2 = i#update 1 in val 2 ) = 
with h handle (let X2 = i#update 1 (2/2 - val 2/2) in val 2 ) 
with h handle (t#update 1 (3/2- lei ^2 = val y2 in val 2 )) 

(fun 2/2 <— > with h handle (let X2 = val 2/2 in val 2)) () 
with h handle (let X2 = val () in val 2 ) 

with h handle (val 2 ) /#update 2 = t#update 2 (2/3. val 2/3) 


3.2. Big-step semantics. In addition to small-step operational semantics, we also provide 
a big-step variant, which is closer to the actual implementation of Eff. Define a result to 
be a pure expression or an operation call: 

Result r ::= vale | /.#ope(x. c) 

Big-step semantics c JJ- r evaluates a computation c to a result r, according to the following 
inductive rules: 

ci 1 J. r c 2 JJ- r 

if true then Ci else c 2 JJ- r if false then ci else c 2 JJ. r 

ci JJ- r c 2 [e/ x] JJ- r 

(match 0 with 0 1 — >■ Ci | succ x 1— > c 2 ) JJ r (match succ e with 0 > — >■ Ci | succ x 1— » c 2 ) JJ r 

c[e/x\ JJ r ci JJ val e c 2 [e/x]JJr 

(fun x i-» c) e JJ r val e JJ val e l # op e (x. c) JJ l # op e (x. c) let x = C\ in c 2 JJ r 

Ci JJ l # op e (2/. c) c 2 [(fun x let rec f x = C\ in Ci)/ f] JJ r 

let x = Ci in c 2 JJ i#op e ( y . let x = c in c 2 ) let rec / x = Ci in c 2 JJ r 

c JJ val e c v [e/x\ JJ r 

with (handler val ihc, | ocs) handle c JJ r 

def 

h = (handler val x Ac„ | ocs) c JJ l# ope ( y . c) (op : A op — > f? op ) gE e 

ocs L # op (e, (fun y : B op 1— > with h handle c)) JJ r 


with h handle c JJ r 
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To relate the two semantics we define an auxiliary relation by the rules 

c c' c r 

val e val e l# op e (x. c ) /,#op e (x. c) c r 

This is roughly the reflexive transitive closure of -w, except that it relates computations to 
results rather than to computations. The small-step and big-step semantics agree in the 
following sense. 

Proposition 3.2. For all computations c and results r, c if r if and only if c r. 

Proof. Both directions of the equivalence proceed by a routine induction. The formalized 
proofs of the two implications can be found in the file small-big . elf. □ 


4. An effect system 

4.1. Subtyping. As in most effect systems, we need to take care of the poisoning prob- 
lem [26]. For example, what should be the type of ignore in 

let ignore = val (fun msg i— >• val ()) in 

let / = if b then (val ignore ) else (val std#write) in 

val ignore 

assuming we have the ground type string and a boolean expression bl If we give it the 
desired type string — > unit ! 0 then there is a type mismatch between the branches in 
the conditional statement, whereas the dirty type string — > unit ! {std#write} loses the 
valuable knowledge that ignore is a pure function. The simplest antidote to the poisoning 
problem is subtyping so that ignore may be given the function type with empty dirt which 
is coerced in the conditional statement to a supertype that matches the other branch. 

For our purposes, a straightforward variant of structural subtyping [6] suffices. We have 
subtyping of pure types A ^ A' and of dirty types C ^ C_, given by the rules 

A! < A C^Cf 

bool ^ bool nat ^ nat unit ^ unit empty ^ empty A -> C < A' — > Cf 

RCR' Cf < C D < Df A < A' A C A' 

E r < E rI C=>D^Cf=>Df A ! A < A' ! A' 

It is easily checked that reflexivity and transitivity of subtyping are admissible. Apart 
from resolving the poisoning problem, subtyping allows us to better deduce the behavior of 
handlers. Consider the computation 

let u = val t in 

let v = (if b then val u else val i ) in 

let h = val (handler val x • • • | u# op xk >— )■ c) in 


Without subtyping we are forced to give both u and v the type E^ L ' L h Therefore, by looking 
at the type of u we cannot tell whether h handles t#op or 7#op, and so we must assume 
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that both may be unhandled by h. With subtyping we may give u the type E ^ which 
makes it clear that h handles r#op. 

4.2. Typing rules. There are two typing judgments, 

Theid and T \~ c : C_ 

stating that an expression e has a pure type A and a computation c has a dirty type C_, 
respectively. Here T is a typing context of the form x\ : A\, . . . ,x n : A n . There is also a 
third, auxiliary typing judgment 

T b ocs : C_/ A 

which states that operation cases ocs all have the same outgoing type C_ and are guaranteed 
to handle operations in A. Most of the typing rules in Figured] are standard, except for: 
Inst: we check that i is one of instances in R, which in turn must be contained in Xe- 
Hand: to check that a handler has type A ! A =>- B ! A', we verify that it converts a compu- 
tation of type A ! A to one of type B ! A', which involves checking three premises. First, 
the value case must take a value of type A to a computation of type B ! A'. Second, all 
operation cases must have outgoing type B ! A'. Third, every operation in A is either 
guaranteed to be handled by ocs, or is contained in A'. 

OpCases-Nil, OpCases-Cons: the auxiliary typing judgment verifies that the operation 
cases have the given outgoing type, and that they cover the given dirt. The empty list 
nil does not cover anything and has any outgoing type. The rule OpCases-Cons checks 
the first operation case, checks the others inductively, and verifies that AC AT R# op, 
where 

A'kJJWop d i f ( A ; u{l# °P } = 

I A otherwise. 

The idea is that we can be sure that an operation case handles l # op only when the type 
of its instance is of the form t#op ^ . 

Op: we first check that e and op belong to the same effect. Then we check that A covers 
not just all possible operations that the operation call may cause (recall that R may 
contain more than one instance), but also any operations in the continuation c. We may 
assume that c has the same dirt, as we can use SubComp otherwise. We use the same 
reasoning in rules IfThenElse, Match and Let. 

With: handlers behave like functions from computations to computations. 

SubExpr, SubComp: these subsumption rules allow us to always assign a bigger type. 

The effect system is safe with respect to the operational semantics: 

Theorem 4.1 (Progress & Preservation). 

Progress: If b c : A ! A then either 

• there exists a computation d such that c d , or 

• c is of the form val e for some expression e, or 

• c is of the form t# op e (x. d) for some i# op E A. 

Preservation: If b c : C_ and c d then b d : C_. 


Proof. Both statements are proved by induction. The formalized proofs can be found in the 
files progress. elf and preservation, elf. □ 
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VAR 

{x : A) G T 
T F x : A 


True False Zero 


r F true : bool T F false : bool T h 0 : nat 


Succ 

The: nat 

F F succ e : nat 


Unit 

r F () : unit 


Fun 

T,x : A h c : C 
r F fun x : A i — > c : A — > C 


Inst 

l £ R C X E 
r F L : e r 


Hand 

T,x \ A\- c v : B\ A' T h ocs : B ! A'/A" A C A" U A' 
r F (handler val x : A H > c v \ ocs ) : A ! A =>• B ! A' 


SubExpr 

The: A A ^ A' 
The: A' 


OpCases-Nil 
T h nilc : C _/ 0 


OpCases-Cons 

Th e:E R (op : A op -> H op ) G T, E 
T,x : A°*,k : B°? -> Ch c: C Thocs:C/A' ACA'di?#op 
r h (e#op x k i-A c | ocs) : CJ A 


IfThenElse 

The: bool T h c\ : C_ T h C 2 : C_ 
F h if e then c i else C 2 : C_ 


Match 

The: nat T h c\ : C_ T, x : nat b C2 : C_ 
r h match e with 0 i — >• Ci | succ x i-> C2 : C_ 


Absurd App Val 

The: empty T h ei : A C Fhe2:A T h e : A 

F h absurdc e : C_ T h e\ e 2 : C_ TF val e : A ! A 

Op 

r F e x : E R (op : A op -> H op ) G E e 
T h e 2 : A op T,y:B°*hc:A\ A Vt G R. l# op G A 

r F ei#op e2 (y.c) : A \ A 


Let 

r F ci : A ! A r,a;:AFc2:B!A 
r F let x = ci in C 2 : B ! A 


LetRec 

TJ:A^C,x:Ah Cl :C TJ:A->Chc 2 :D 


r F let rec / x : A — > C_ = ci in o? : D 


With 

FFe:C^D Thc:C 


T F with e handle c : D 


SubComp 

r F c : C C^C! 


Thc:C' 


Figure 1: The typing rules of core Eff . 


Corollary 4.2 (Safety). A terminating computation of type A \ A returns a value of type A, 
or calls an operation in A. 

In particular, a terminating computation of type A ! 0 does not call any operations and 
returns a pure value of type A. 

Example 4.3. Let us see what the effect system tells us about Example 13.11 We may 
give the reference i € X ref type refW. Then the computation c has the dirty type 
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nat ! {4#lookup, z#update}, and the handler h the type 

(nat ! {r#lookup, r#update}) => (unit ! {r#update}) 

because it handles both lookup and update, but then calls update in the value case. This 
update also changes the type of computation from nat to unit. 

If we give l the less precise type ref^’ 1 }, the dirt of c is 

A c = {r#lookup, </#lookup, /#update, /^update} 

while the best type we can give to h is (nat ! A) =>• (unit ! A). Since {i, /'} is not a singleton, 
we cannot give any guarantees on what operations are handled. 


4.3. Skeletal types. We relate the pure and dirty types to ML-style types by an operation 
which erases all effect information to produce a skeletal type. We will use these later to 
obtain a coherent semantics of types. The skeletal types are defined as follows: 

Skeletal type S, T ::= bool I nat I unit I empty I S — » T | E I S => T 


There is no distinction between pure and dirty types anymore. The typing rules for skeletal 
types are like those for pure and dirty types with the effect information omitted, for instance 


Inst’ Hand’ 

l G X e r, x : A s b c v : S f h ocs : S 


OpCases-Nil’ 


F b i : E F h (handler val | ocs ) : A s => S F h nilc '■ C_ s 


OpCases-Cons’ 

T\-e:E (op : T°p B°P) £ V, x : (H°P) S , k : (H op ) s -> S b c : S 

r b (e#op x k i — > c | ocs ) : S 


r b ocs : S 


Op’ 

r b ei : E (op : H op -A H op ) e E E T b e 2 : (A op ) s T, y : (5 op ) s bc:S 

r b ei#op e 2 (y. c) : S 

The remaining rules remain unchanged as they do not mention effects, while subsumption 
rules are removed. To every pure type A and a dirty type C_ we assign their skeletal versions 
A s and C_ s , which are like A and C with region and dirt removed. The skeletal version T s 
of a typing context T is obtained by taking the skeletons of the types in T. We summarize 
the properties of skeletal types: 


Theorem 4.4. 


(1) 

If A ^ B and 

D_ then A s = 

= B s 

and Cf = 

= IT. 

(2) 

If 







T b e 

: A 

and 

Tbc:C 


then 







T s be: 

A s 

and 

V s b c : C s 


(3) In a given context, an expression and a computation has at most one skeletal type , with 
a unique typing derivation. 
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Proof. The first statement holds by an induction on the derivation of A ^ B and C ^ D_. 

To prove the second statement, observe that a typing derivation may be mapped to the 
corresponding skeletal version rule by rule, except for subsumption rules. But these can be 
simply omitted from the typing derivations because A ^ B and C_^ D imply A s = B s and 
C s = D_ s by the first statement. 

The last statement holds by inversion: in any situation at most one skeletal typing rule 
applies in at most one way. □ 

A consequence of the theorem is that if a computation c has dirty types C_ and D then 
C_ s = D_ s , hence C_ and D. differ only in the effect information. An analogous property holds 
for expressions and pure types. 

5. Denotational semantics 

We use standard domain theory to provide an adequate denotational semantics of core 
Eff . We shall use w-cpos as domains, but presumably a different kind of domains could be 
used, as long as they support the standard constructions, in particular solutions of domain 
equations, and are amenable to Pitts’s theory of minimal invariant properties M- We refer 
to [Tj for background on domain theory and denotational semantics. 

We define a predomain to be a poset in which chains (ascending sequences) have 
suprema, while a domain is a predomain with a least element _L. A continuous map is 
a monotone map which commutes with suprema of chains. If D is a predomain and if is a 
domain the set D — > E of all continuous maps forms a domain. The ordering on continuous 
maps is pointwise. A continuous map is strict if it maps 1 to 1. The set D E of strict 
maps between domains D and E forms a subdomain of D — > E. 

5.1. Computation domains. We first build domains that will serve as the meanings of 
computation types. Let A be a predomain, I an index set, and for each i € I let Aj and Bi 
be predomains. We seek a domain T satisfying the domain equation T = F(T ) where F is 
the functor 

F(D) = (A + A* x (Bi — > -D))j_. 

Following m we work in the category of domains and strict maps, and take T to be a 
minimal solution in the sense that it possesses the minimal invariant property. The usual 
limit-colimit construction |T) Chapter 7] yields such a domain. As domain equations go, this 
one is quite simple because T occurs only covariantly. The elements of T can be thought of 
as trees whose leaves are tagged with elements of A or _L, and whose nodes have branching 
types Bi and are tagged with elements of Aj. The trees need not be well founded. 

The minimality of T yields a recursion and an induction principle. The recursion 
principle says that for any domain D, a continuous map / va i : A — » D, and continuous 
maps /j : Aj x ( Bi — > D) — > D for i £ /, there is a unique strict continuous map / : T — o D 
such that 

/(in va iOr)) = /vaiOr) for x <E A, 

/ (inj(y, k)) = fi(y , / ok) for y G Aj and k : Bj -> T. 

The induction principle for T applies to admissible predicates on T, i.e. , those that hold for 
T and are closed under suprema of chains. Precisely, if <f> is an admissible predicate on T 
such that 
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(1) 0(in va |(a;)) for all x € A, and 

(2) for all i £ I, x £ Aj, and k : Bi — > T, if Vy £ Bi. <f>(n(y)) then </>(irij(a;, «)), 
then (j)(t) holds for all t £ T. 

For any I , the construction of a minimal solution Tj(A, ( Aj)j , (-Bj)i) from the input data 
A (A) ig/, forms a locally continuous functor 

Tj : pCpo x pCpo^ x (pCpo op ) ; — » Cppo. 

Here Cppo is the category of domains and strict continuous maps, while pCpo is the 
category of predomains and partial continuous maps which are defined on open subsets (an 
upper set which is inaccessible by suprema of chains). The functor will appear later on in 
a larger system of recursive domain equations. 

5.2. Semantics of skeletal types. We interpret pure and dirty types as predomains and 
domains, respectively. A typing context is interpreted as a cartesian product of predomains, 
and a typing judgment as a continuous map. However, typing judgments do not have unique 
derivations because of the subsumption rules, and so we have to worry about coherence. 
That is, when we define the meaning of a typing judgment by induction on its derivation, 
we need to make sure that the result does not depend on the choice of derivation. We 
accomplish this by providing a semantics which factors through the skeletal types from 
Section 14.31 
Let 

Q = {i#op | BE. i £ X E A op £ £_e} 

be the set of all operations. If dirts could be infinite, A ! H would be a dirty type expressing 
the fact that any effect could happen. 

To each skeletal type S we assign a predomain [5] e and a domain |5] c as follows: 
[bool]] e = {ff , ft}, [nat]] e = N, 

[unit]] e = {*}, [empty]] e = 0, 

[5 — ► T] e = [S] e -> [T] c , m e = X E , 

[5 => Tie = [Sic - PA, 

and 

ISjc = r n ([S] e , ([(A op )l e ) t#op , ([(iTAleWA 
These should be read as a system of domain and predomain equations indexed by the 
skeletal types. There are possible circularities in the system because the equation for [5] c 
refers to possibly larger skeletal types (A op ) s and ( B op ) s . As in the case of computation 
domains, we take the minimal solutions which enjoy the minimal invariant property. 

To each pure type A and dirty type C_ we assign a skeletal predomain [A] and skeletal 
domain [CJ by setting 

[A] = [Ale and [CJ = {C%. 

The first part of Theorem 14.41 guarantees that A ^ B and C_ ^ D imply [A] = [HJ and 

m = irn- 
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5.3. Semantics of expressions and computations. The meaning of a typing context T 

■i' l • A\, ■ ■ ■ ■ x n . A n 

is 

[r] = Nx-x[4], 

We interpret typing judgments 

T \~ e : A and T \~ c \ C_ 

as continuous maps 

[r h e : d] : [r] A {A} and [T h c : Cj : [T] -A !£]• 

When no confusion can arise we abbreviate these as [e] and [c]. The definition proceeds 
by induction on the derivation of the typing judgment. Given an environment rj G [T], the 
base rules for expressions and the successor rule are taken care of by 

[T b Xi : AiJrj = r)i [r b false : bool]]?/ = ff 

[r b () : unit]]?/ = * [r b true : bool]]?/ = ft 

[T b 0 : nat]?/ = 0 [r b succ e : nat]?/ = ([The: nat]?/) + 1 

[Tbt: E R jrj = t, 
and the abstraction rule by 

[T h (fun x : A i — y c) : A — y C\r] = \a G [A] . [T, x : A b c : C] (?/, a) 

For the handler rule we set 

[T h (handler val x : A H > c v \ ocs ) : A ! A => B ! A 7 ]] = h 
where h : PI — > |yl ! A] — o \B ! A'] is defined by recursion on \A ! A]: 

%)( X) = X 

^-( r /)(' n val(a)) = {T,X : Ah c v : 
h(r]){\n L#op (a, k)) = [ocs] t#op (? 7 , a, ^( 77 ) ok) 

The auxiliary map 

locsl #op : IT] x {A°V} x [B 0 * -» B ! A'] — > \B ! A'] 

is defined by 

lnilcj L # op {ri,a,K) = in t#op (a, /t) 

[e'#op ' xk i-A c | ocs] rfop (?/, a, k) = 

( [r, x : A° v , k : B° v — > B\ A' b c : B\ A '](?/, a, k) if ([e']?/)#op' = ?#op, 
|[ocs] t #op(?/, a, k) otherwise. 

Finally, if T h e : A' is derived from the premises T b e : A and A ^ A! by the subsumption 
rule, we set 


[The: A'Jr] = [r be: Ajr/. 
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The definition is meaningful because A ^ A' implies [[^4] = [bl']]. The meaning of pure 
computations and operations is 

[T b val e : A! A jr, = in va |([T e \ A\) 

[[T b ei#ope 2 (y.c) : A\ Ajr, = in| ei ] J?#op ([e 2 ]? 7 , Xb € [-B op ] . [T, y : B°v b c : A ! A] ( 77 , b)). 
The meaning of elimination forms is 

|T b with e handle c : Djr, = (|T b e : C =b i2l ? ?)([r b c : CJ??) 


[T h if e then ci else c 2 : Cjr, 

|r b absurd e : Cjr, 
[T h ei e 2 : Cjr, 


I [r b ci : Cjr, if [[T h e : booljr? = ft, 
| [r b c 2 : Cjr, if [T b e : booljr? = ff 
T 

([Th ei :4AC]#rhe 2 :4]) 


and 


[T b (match e with 0 1 — >■ ci | succ x 1 — > c 2 ) : Cjr, = 

J [[T h ci : C]?? if [T b e : natj?? = 0, 

[T, x : nat b c 2 : Cj(rj, n ) if [T b e : natfljy = n + 1. 

To give semantics of let binding, we first define the lifting of a map / : [A] — > \B ! A] to 
be the map ft : \A ! A] — y \B ! A] defined recursively by 

/ f (-L) = J-, 

/ t (in V ai(a;)) = f(x), 

in t # op (x, k )) = in t # op (x, / f o k). 

Then we set 


[T b let x = ci in c 2 : B ! A]]?/ = 

(AaG [A].[r,s: A b c, : B! A]fa,a))t([T b ci :A\A}rj). 
The meaning of a recursive function definition is 

[T b (let rec / x : A — > C_ = ci in c 2 ) : Cjr, = [T, / : A — » C_ b c 2 : (7] ( 77 , g) 
where g : [A] — > [C] is the least fixed-point of the map 

g i-A (Aa € {A} . ld}(r,,g,a)). 

Finally, just like for expressions, if T b c : Cf is derived from the premises T b c : C_ and 
C ^ Cf by the subsumption rule, we set 

[T b c : Cfjr, = [T b c : Cjr,. 

This concludes the definition of denotational semantics of expressions and computations. 

Theorem 5.1 (Coherence). All derivations of a typing judgment give it the same meaning. 

Proof. The semantics of T b e : A and T b c : C_ factor through the associated skeletal 
derivations T s b e : 4 s and T s b c : C_ s , respectively. This is so because the semantic 
rules given above clearly factor through the associated skeletal rules. In other words, they 
ignore the effect information and the subsumption rules. Uniqueness of meaning is thus 
consequence of the uniqueness of skeletal derivations, cf. Theorem 14.41 


ce □ 
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5.4. Semantics of effects. In the terminology of John Reynolds [23] the semantics given so 
far is intrinsic, while the semantics of effects given below is extrinsic. This is in accordance 
with our understanding that effect information is descriptive rather than prescriptive: a 
function / of type (A — > B ! A) — >■ B' ! A' should accept any function g of type A — > B ! A", 
even if A" A, although it has the property that if A " C A then f(g ) calls only operations 
in A'. 

For each pure type A and dirty type C_ we define subpredomains p] C [A] and 
subdomains |CJ C |(7] of those elements that behave according to the effect information. 
The ground types are easy: 

Ibool| = [bool]], |nat] = [nat], [[unit]] = [unit], 

[[empty] = [empty], |E fl ] = R- 

For function types, handler types, and dirty types we would like to solve the following 
system of equations with unknowns p] and |(7] where A and C_ range over pure and dirty 
types, respectively: 

P -a C] = {/ £ P] [C] | Mx £ P]. f{x) £ |C]}, 

m => = {h e icj -o m i V* e ioi . k(t) £ my, 

P ! A] = {t £ {A ! A] | t = J_ V (3x £ P], t = in va |(x)) V (5.1) 

3i#op £ A, y £ P 0p ] , k £ [£ op -> A ! A] . 

(Vz £ p op ], K (b) £ P ! A]) A t = in t#op (y , «)}. 

The last rule says that t £ P ! A] when it is J_, or of the form in va |(x) for some x £ p], 

or of the form in l#op (y, k) for some y £ p op ] and k £ |F> op — > A ! A]. 

The system is potentially problematic because the types Al op and B° v introduce circu- 
larities in the last equation. We apply Pitts’s theorem Cl Theorem 4.16] about existence 
of invariant relations to obtain a solution that satisfies an induction principle, see Theo- 
rem IQ below. For Pitts’s theorem to apply we must verify that our conditions form an 
admissible action on admissible relations, as defined in m Definition 4.6]. The relational 
structure in question is that of m Example 4.2(h)] for which the accompanying notion 
of admissibility is the one we are using, cf. m Example 4.5(h)]. The locally continuous 
functor is the evident one, while its admissible action on relations is read off (15.11) . The 
admissibility of the action follows from d Lemma 6.6]: the first two actions in (15.11) are 
considered explicitly, while the third one is a composition of actions from the cited lemma. 
The solution so obtained possesses the following induction principle. 

Theorem 5.2. Suppose 4> is an admissible predicate on \A ! A] such that 

(1) 0(in va |(a)) for every a £ p], and 

(2) for all t # op £ A, a £ p op ], n € |L> op — > .A! A], if Mb £ |i? op ]. 4>(n(b)) then 
</>(in tjf fo P (a,/c)). 

Then <j>(t ) for all t £ P ! A] . 

Proof. Because we defined |— ] mutually for all types, we first extend < f> to be constantly 
true on types other than A ! A. Then our theorem becomes an instance of the induction 
property m Theorem 6.5]. The admissible action required for the application of the 
theorem is obtained using [T4l Lemma 6.6]. □ 
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The semantics of effects and the semantics of expressions and computations fit together: 

Theorem 5.3. If T \~ e : A and T h c : C_ then for all r j G |T| = |Ai| x • • • x |A n J ; we 
have 

lr^:%£ PI and [The: Cjr) G ICJ. 

Proof. The proof proceeds by induction on the derivation of the typing judgment. All cases 
are easy, except for the typing rule for a handler 

T b (handler val x i-a c v \ ocs ) : A ! A => B ! A 7 
First, we claim that if the auxiliary judgment 

T b ocs : B ! A'/ A c 

is derivable then locs} L #op{Vi a , k) G |-B ! A']] for all l # op G A 7 U A c , rj G |T]], a G |A° P |, 
and n : |-B op — > B ! A 7 |. Assuming the claim has been established, the above handler rule 
follows immediately. 

The proof of the claim proceeds by induction on the derivation of the auxiliary judgment. 
For nil , we have A c = 0 and the claim obviously holds. The other possibility is 

T b (e#op / x k i — y c | ocs) : B ! A' /A' c 

for some T b ocs : B ! A' / A c and A' c C (A c U R# op). Define d = [T b e : E R }r) and consider 
two cases. First, if i 7 #op 7 = i # op then 

[e^p' x k i-A c | ocs] t#op ( 77 , o, k) = [T, x : A° v , k : B° v — )■ B ! A' b c : B ! A'] ( 77 , a, k), 

and we may apply the induction hypothesis (for the whole theorem) to c. Second, suppose 
fttoip' 7^ /,#op. Then the assumption /.#op G A 7 U A' c implies l# op G A 7 U A c . Indeed, if 
z#op G A 7 there is nothing to prove, and if i#op G A' c C (A c U i?,#op), then either R is not a 
singleton and A c U R# op = A c , or R = {i 7 #op 7 } and /,#op fL R. In any case, it follows that 

[e#op 7 x k i-A c | ocsJ t#op ( 77 , a, k) = {ocsJ L#op {r], a, k) 
and r b ocs : B ! A 7 /A c . Thus we may apply the induction hypothesis. 

5.5. Soundness and adequacy. The soundness and adequacy theorems state that oper- 
ational semantics and denotational semantics fit together. One is an easy induction, while 
the other is proved using standard technique of formal approximation relations, e.g., see [H 
Theorem 6.3.6]. 

Theorem 5.4 (Soundness). I/bc:C and c c! then [b c : CJ = [b c! : C]. 

Proof. We just have to walk through all the defining rules for and verify that they do 
indeed preserve the meaning of c. □ 
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To tackle adequacy, see Corollary 15.81 below, we define formal approximation relations 
<U and <c whose intuitive meaning is that an element of [A] or [C] approximates a closed 
term of type A or C_. Given d E [AJ and a closed expression e : A, we define d <u e by: 

d Obooi e -<=>■ (d = ft A e = true) V (d = ff A e = false) 
d <n a t e d = n A e = succ" 0 


d Amit C 

d <a->c e 

d < e r e 

d <c=^d e 


d = -k A e 


o 



Vr/, d . (d' <a => d(d 7 ) e e 7 ) 
d = e 

Vd 7 , c. (d 7 <q_ c =k c?(ci / ) <d (with e handle c)) 


Simultaneously we define when d E [[.A ! A] approximates a closed computation c : A! A, 
where d <a ! A c holds when 

• d = J_, or 

• d = in va i(d 7 ), c JJ. val e and d 7 < 1,4 e, or 

• d = in t#op (d / , k), c JJ- /,#ope (y. d), d! <u° P e, and if d" <b°p d then n(d") <a ! A d[e" /y\. 

The definition of <U!A refers to types A op and B° v which are possibly larger than A, thus 
we again use m Theorem 4.16] to establish existence of minimal such <a and <c, much 
like for the recursive types considered in m Section 5]. 


Lemma 5.5. If d<A\A c - an d c d then d <a ! A c - 


Proof. There is nothing to prove if d = _L. The other two cases follow because c c' and 
d JJ- r imply c JJ. r. For instance, if d 0^1 a d holds because d = in va |(d'), c JJ. val e and 
d! <a e for some d! and e, then d <a ! A c holds because c d implies c JJ- val e and so we 
may reuse d' and e. □ 


Lemma 5.6. The relations <a and < c are closed under suprema of chains in the first 
argument. The relations < c relate _L to every computation. 

Proof. The second statement holds by the definition of <1 q. For the first statement we 
proceed by induction on the type. The base cases hold because the predomains for ground 
types are flat. For A — » C, suppose (d n ) n is a chain in [[A -* CJ and d n <1 a-$-c e f° r a ll n - 
Consider any d', d such that dl < 1,4 d . Then d n (d') <c_cd for all n. Suprema in \A — > CJ are 
defined pointwise, so we can use the induction hypothesis for C_ and get 

(Vn dn)(d') = Vn d n(d') <C ed , 

hence \J n d n <c e as desired. Handler types are treated similarly. Consider a computation 
type A ! A, a closed computation c : A! A and a chain (d n ) n in \A ! A] such that d n <cc for 
all n. There are three kinds of chains in [A ! AJ: 

• (dn) n is constantly _L: then \J n d n = l<pc. 

• for large enough n there are d' n such that d n = in va |(<i(j): then (d' n ) n form a chain in JAJ. 
Because operational semantics is deterministic, there exists a single e such that c JJ. val e, 
and d' n <a e. By induction hypothesis for A we have \J n d' n <u e, from which \J n d n <a ! A c 
follows because \/ n d n = in va i (\J n d' n ). 

• there are l and op such that for large enough n there are d' n and d n such that d n = 

in^op (d' n , n n ): this case is treated analogously to the previous one. □ 
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Lemma 5 . 7 . Let T be the context x\ : A\, ... ,x n : A n . Suppose that for each 1 ^ i ^ n we 
have di € [Aj] and a closed expression b e* : Aj such that di <A. t ej. 

( 1 ) IfT\~e:A then [r h e : Aj(di , . . . , d n ) <U e[ei/xi, . . . ,e n /x n }. 

(2) IfT he: C then [T h c : CJ(d 1 , . . . , d n ) <c_c[ e i/ x i, ■ ■ ■ ,e n /x n \. 

Proof. We prove the statements by induction on the derivation of the typing judgments. 
Let rj = (di, . . . , d n ) and a = \e\/x \, . . . , e n /x n \. We write [a,e/x\ for the substitution 
[ei/xi, . . . , e n /x n , e/x\. Throughout we assume that bound variables occurring in various 
terms do not appear in a: 

Cases Var, True, False, Unit, Zero, Inst: these are all trivial. 

Case Succ: T h (succ e) : nat. By the induction hypothesis, we have [e]r/ <d nat ea. Next, 
notice that the closed expression ea : nat must be succ^O for some k, hence [e]?7 = k, 
and so 

[succ e]]?7 = (k + 1) <n at succ (ea) = (succ e)a. 

Case Fun: T h (f un x i — > c) : A — > C_. If d! < a e! then by the induction hypothesis for c 

[T, x : A I- c] (77, d!) <c_ c[a , e'/x] . 

Because [T, x : A h c] (77, d!) = ([T h fun x i-A cjr;) d' and 

((fun x eA c)a) e' = (fun x i-A ca) e' c[a, e' /x\, 

we may use Lemma 15.51 to get the desired conclusion 

([T h fun x i-a CJ77) d' <c_ ((fun x t-A c)a) e' . 

Most other cases in the proof follow the same pattern, so we shall not explicitly mention 
uses of Lemma 15.51 anymore. 

Case Hand: T h (handler val n — )• c„ | ocs ) : A ! A =>■ B ! A 7 . We abbreviate the handler 
as h. Assuming d <u 1 a c we need to show that 

<B !A' (with ha handle c). 

We proceed by an induction on d: 

• If d = J_ then the conclusion follows because Ihjrj is strict. 

• If d = in va |(cf ) then d< U ! A c implies c Jj- val e' and d! <1^4 e! for some e! and d! . In this 
case, by induction hypothesis for c„, 

(lhjrj)(d) = [r,r:Ah c v J(r],d') <b\AC v \a,e'/x\, 

and 

(with ha handle c) -w • • • (c v a)[e' /x\ = c v [a, e' /x\. 

• If d = in t#op (d', k) then d <a ! A c implies c JJ- l# ope' (y. c'), d! <a°p e 7 and k <_b°p->A! a 
( fun y 1 — > c'). Now 

(M? 7 )(in t #op (d',K)) = [ocs] t # op (?7, d r , \h\iq o k) 

and 

(with ha handle c) ■ ■ ■ -w (ocs a) L # op (e r , (fun y 1 — > with ha handle c 7 )), 
therefore it suffices to prove 

[ocs] t # op (?7, d' , Ihjrj o k) <b\A' (ocs a) i#ov (e' , (fun y i-A with ha handle c 7 )), 
which we do by induction on the length of ocs. When ocs is nil the statement becomes 
in t # op (d\ Ihjr) o k) <i_b!A' ope 7 (y. with ha handle c 7 ). 
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We already know d! <a° p e' , and still need 

lh}r](n(d")) <b\A' (with ha handle d[e" / /y\) 

assuming d" <b° p e 7/ . This follows from the available induction hypotheses. 

When ocs is (//#op' x k i-A c" | ocs ') there are two further subcases: 

— if i#op = //#op 7 then we get 

|T, x,k\~ d'J (77, d, [ A] 77 o k)< B \ A' 
c"[a, d /x, (fun y 1— > with ha handle c')/k ] 

which holds by induction on c" , 

— if /,#op 7^ //#op 7 then we are left with 

locs'} L#ov (r],d', [%ok)< b!A / 

( ocs ' a ) L#0 p (e, (fun y (->• with ha handle c')), 

which is just the induction hypothesis for ocs'. 

Cases IfThenElse, Match, Absurd: We consider only 

r (- (if e then c\ else C2) : ( 7 , 

as Match is similar and Absurd is vacuous. Because ea is a closed expression of type 
bool it is either true or false. Let us take a look at the first possibility. By induction 
hypothesis for c\ we have [cijry <c_ c\a. Again, because [if true then c\ else C2J?? = 
[cij?7 and 

(if true then c\ else cd)a cicr 

it follows that 

[if true then c\ else C 2 \y<c (if true then c\ else C2)a, 

as required. 

Case App: L h e\ e '. 2 : C_ where L h e\ : A — > C_ and T h e ' 2 : A. By induction hypotheses 
for e[ and e ' 2 we have \e\ ] q <a— >c e '\ a and [e 2 ] 77 <a ^2 a, therefore by the definition of 
— >C j 

[e'i e' 2 l V = ([e , il??)([e 2 lr ? ) <g_ {e\a){e' 2 a) = {e\ e' 2 )a. 

Case Val: T h val e : A! A. By induction on e we have [ejr 7 <u e< 7 , therefore by the second 
clause in the definition of <1,4 ! A 

[val eji] = in va |([ej?7) <U ! a val (ecr) = (val e)a. 

Case Op: T h i#ope(y. c) : A! A. This case works much like a combination of Val and 
App, so we omit the details. 

Case Let: T h (let x = c\ in C2) : B ! A. This case is treated like a handler which only 
has a val case. 

Case With: T h with e handle c : D_ where T \~ e \ C_=> D_ and T \~ c : C_. By induction 
hypotheses we have \e\iq <c=?D e<r and [c]ry <c_ ca, therefore by the definition of <c=LD 

(I e l r /)(I C 1 T ?) < D_ (with ea handle ca). 

The left-hand side equals [with e handle c : 221 7 ? and the right (with e handle c)a, so 
we are done. 
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Case LetRec: T b let rec fx = c\ in C 2 : D. After a short calculation the problem 
reduces to showing that 

g <a— > c (fun x i-A let rec fx = c\a in c\ a) 
where g is the least fixed-point of the operator : [A — > C] — > [A — > CJ , defined by 

d>(/i) = A a <G {A} . b cij (?7 ,h,a). 

By Lemma 15.61 it suffices to show that 

h <a— >C (fun x >->■ let rec fx = cicr in ci<r) 

implies 

<&(h) <U— >c (fun x i-A let rec fx = c\o in c\ a). 

This amounts to proving that if d <u e then 
$(h){d) = [T,/,ib cil ( 77 , h, d) 

<£Ci[ct, (fun x i-a let rec fx = C\o in C\a)/ f, e/x], 

which holds by the induction hypothesis for c\. 

Case SubExpr, SubComp: For SubExpr, take T b e : A' where T b e : A and A ^ A' . 
From induction hypothesis, we get [T b e : AJrj <a ea. Since [AJ = [A'], we have 
<U = <A'- Additionally, [Tbe: A'] = |[T b e : AJ, hence |e]]7/ <1^4/ ecr. For SubComp, the 
proof is similar. □ 

Corollary 5.8 (Adequacy), //be: unit ! A and [cj = in va |(*) then c JJ. val (). 

Proof. By the previous lemma [cj <i U nit!A c. Therefore, if |c] = in va |(*) then c JJ- val () by 
the definition of <i un it ! A • HH 

The stated adequacy suffices for our purposes, but of course similar statements holds 
for other ground types. Regarding operations, if [cfl = \r\ l _# op (d, k), then t#op G A and so 
c JJ. i#opek for some e and k such that [ej = d and [fe] = k. Therefore, if [cj / T then 
c JJ- r for some result r. 


6. EQUATIONAL REASONING 

6.1. Contextual and denotational equivalence. In this section we provide principles 
that allow us to reason about programs. Let us first recall how contextual equivalence is 
defined. An expression context 6 is a computation with several occurrences of a hole [] in 
positions where an expression is expected. When the hole is plugged with an expression e 
we get a computation £ [e] . A computation context £ is defined analogously, except that the 
holes appear where computations are expected. 

We say that expressions e and e! are contextually equivalent, written e ~ e', when 
for all expression contexts £ such that £[e\ and £\e'\ are both of type unit! A, we have 
£[e\ JJ. val O if and only if £[e'] JJ- val (). Contextual equivalence of computations is 
defined analogously. 

Contextually equivalent expressions or computations may be interchanged anywhere 
in the code. Therefore, it is quite useful to know that a certain contextual equivalence 
holds, but unfortunately it is difficult to work directly with contextual equivalence. Luckily, 
denotational equivalence is more easily handled and is related to contextual equivalence by 
the adequacy theorem. 
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We write e = e' and c = d when the denotations of two expressions or computations 
are the same. More precisely, if T b e : A and T h e 1 : A then T b e = e! : A, or just e = e', 
means [r h e : A] = [r h e! : A], and similarly for computations. 

Proposition 6.1. Denotationally equal expressions are contextually equivalent, and likewise 
for computations. 

Proof. Suppose e = e 1 and consider an expression context 8 such that 8 [e] and 8 [e '] both 
have type unit ! A. Assume 8 [e] JJ- val (). By soundness of denotational semantics \8 [e]J = 
in va i(*). By assumption |ej = [e'J and because denotational semantics is compositional it 
follows that [£[e]J = [£[e']]]. Now by adequacy 8 [e'] 1,1 val (). The proof for computations 
is the same. □ 


Denotational equivalence is a congruence and is preserved by well-typed substitutions. 
It validates the following / 3 -rules, where the various expressions and computations have 
suitable types, and h stands for handler val x H > c v \ ocs: 

if true then c\ else C2 
if false then c\ else C2 
match 0 with 0 i — >• ci | succ 11AC2 
match (succ e) with 0 1 — >• ci | succ 11AC2 

(fun u-)cle 


let x = val e in c 
let x = ei#op e2 ( y ■ ci) in C2 
let rec f x = c\ in C2 
with h handle (val e) 
with h handle (/.# op e ( y . c )) 


ci 

C2 

ci 

c 2 [e/x\ 

c[e/x\ 

c[e/x\ 

ei#ope2 ( y . let x = ci in C2) 

C2[(fun x let rec / x = c\ in c±)/f] 
c v [e/x\ 

ocs L # op (e, (fun y 1— )• with h handle c)) 


We also have the following r/- rules, provided the expressions and computations have easily 
guessed types: 


e 


o 

e 

c 

c[e/x\ 

c[e/x\ 

c[e/x\ 


fun jam 
let x = cin val x 
if e then c[true/x] else c[false/x] 
match e with 0 1 — > c[0/x] | succ y 1— »• c[succ y/x \ 

absurd e 

We omit the proofs because they just involve unfolding of semantic definitions. An exception 
is the 77-rule for let binding, which is proved by induction in the next section. 

A variety of other equivalences is readily validated, for example 

let x = ci in C2 = with (handler val x 1— >• C2 I nil ) handle ci 
and the “associativity” of let binding m 

let x = (let y = ci in C2) in C3 = let y = ci in (let x = c 2 in C3), 
where y must not occur freely in C3, see [23 El] for other examples. 
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6.2. An induction principle for effects. The induction principle for the computation 
domains from Section O is useful for deriving general laws that do not depend on a partic- 
ular choice of effects. It is less useful for specific examples which involve a carefully chosen 
set of effects and handlers, because it forces us to consider operations that have nothing to 
do with the situation at hand. The induction principle Theorem 15. 21 remedies the drawback. 

A typical application arises when we prove an equivalence of the form £[c] = £'[c\ : C_ 
for all computations c of a suitable type A! A. The computation contexts £ and £' are 
interpreted as continuous maps [£],[£’'] : \A ! A] — >• [CJ, and the equivalence may be 
phrased as 

VtepUA]. [£](i) = [5'](t). 

The equality inside the quantifier is an admissible predicate on |A ! A| , so the induction 
principle applies. It is a bit cumbersome to perform the proof using the semantic brackets 
[— ] all over the place. Instead, with a bit of flexibility in notation, we can write the proof 
in a syntactic manner as follows: 

(1) We write T for a non-terminating computation, e.g., let rec fx = fx in /(), and 
check that £[_L] = 5 7 [T]. 

(2) We verify that £[val e] = £ ; [val e] where e is a meta-variable of type A. 

(3) We verify, for each i# op G A, 

£[i#ope(y.ny)\ = £'[t#op e (y. k y)}, 

where e is a meta- variable of type A op and k is a rneta- variable of type B op — > A ! A. 
The induction hypothesis is that £[ne'} = £'[ne'] for all expressions e' of type B° v . 

We apply the method to prove the r/-rule 

let x = c in val x = c 

by induction: 

(1) (let x = T in val x) = T because let is strict in both arguments, 

(2) (let x = (val a) in val x) = (val x)[a/x\ = val a by a /3-rule for let, 

(3) The induction step is proved by 

let x = (/,#op e (y. ny)) in val x 

= r#op e (y. let x = k y in val x) 

= ;.#ope {y.ny) 

where we used a /3-rule in the first step and the induction hypothesis for ny in the 
second. 

A non-trivial application of the induction principle is presented in Section \7 . 21 

7. Example: mutable references 

As a more elaborate example we consider mutable references. In core Eff they are imple- 
mented by the effect ref with operations 

lookup : unit — > A and update : A — » unit, 
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where A is a fixed pure type (in full Eff we could use a parameter). The handler which 
handles the reference given by an expression r : ref A> is defined by (the underscore _ 
indicates an ignored parameter): 

state r = handler val x H y val (fun s H > val x ) 

| r#lookup_ k i — y val (fun s i-a let / = k s in / s) 

| r#update s' k ^ val (fun s H >• let f = k Q in / s') 

This is just the usual monadic-style treatment of state which wraps a computation into a 
state-carrying function. For any instance i € Z re f , pure type B, and dirt A, the computation 
state,, has the type 

B ! ({/,#lookup, z#update} U A) =>- {A — > B ! A) ! A. 

The type says that the handler erases lookups and updates of i from a computation. The 
return type ( A -a B ! A) ! A has an outer dirt A because effects could happen before the 

first lookup or update. Note that the double dirt would not arise if we took the call-by- 

push-value approach to handlers m- 

The handler wraps a handled computation c of type B ! A into a function expecting the 
current state, which explains the type A — > B ! A. In practice such a function is immediately 
applied to an initial state e of type A (such a final transformation of handled computations 
is so common that in full Eff handlers have a special finally case just for this purpose): 

let / = (with h handle c) in / e 

The type of this computation is simply B ! A. In particular, if the only effects in c are 
lookups and updates of l, we get a pure computation. 

If the type of r is weaker, for example ref we are not able to deduce anything 

useful. The best we can do is 

state r : B ! A =£- [A — t B ! A) ! A 

for any dirt A. 

We may handle several references at once by wrapping a computation into several 
handlers. For example, let c be the computation which swaps the contents of two references: 

let y i = ii#lookup () in 

let r/2 = /.2#l°°kup () in 

let _ = ri#update?/2 in 

let _ = i2# u pclate yi in (val O) 

By itself, c has the type 

unit ! {ii#lookup, ii#update, i2#l°°kup, t2#update}, 

When c is wrapped by the handler /12 = state, 2 , 

let /2 = (with /12 handle c) in / 2 e2, 

the type becomes unit ! {ii#lookup, ii#update}. When the handler h\ = state tl is used 
on top of that, 

let fi = (with hi handle (let /2 = (with /12 handle c) in /2 62)) in fi e± 
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we get the pure type unit ! 0. Beware, it is important that the state is initialized at the 
correct point in the computation. For instance, 

let fi = (with h± handle (with /12 handle c)j in (let /2 = f\ e\ in /2 

does not do the right thing. We are warned about possible trouble by the effect system 
which gives the computation the type unit ! {ii#lookup, £i#update} — the operations for 
i\ are escaping the handlers! A less modular way of handling two instances is to create a 
new handler with four operation cases, two for each of the instances. 

7.1. Reasoning about references. With handlers the workings of a computation may be 
inspected in a highly intensional way. Consequently, there are few generally valid observa- 
tional equivalences. However, when known handlers are used to handle operations, we may 
derive equivalences that describe the behavior of operations. The situation is opposite to 
that of m, where we start with an equational theory for operations and require that the 
handlers respect it. 

We demonstrate the technique for mutable state. Let h = state,, and abbreviate 

let / = (with h handle c) in / e 
as [c, e] . Straightforward calculations give us the equivalences 

77[(r#lookup () (y.c)),ej = U[c[e/y},e\ 

77[(/#update e' (_ . c)), e] = 77[c, e'] 

7i[vale',e] = val e', 

for instance, 

"H[(/,#update e' (_ . c)), e] 

= let / = val (fun s 1 — > let f' = (fun _ 1 — )• with h handle c) () in f' e') in / e 
= let / = val (fun s i-A 77[c, e']) in / e 
= (fun s i-> "H[c, e^e 
= 7i[c, e'\. 

These suffice for simple equational reasoning about state. If we read them as rewrite rules 
they allow us to progressively transform a computation to a simpler form. In fact, the 
transformations mimic the usual coalgebraic operational semantics for state |18j . 

Of course, a realistic computation will contain several handlers. As long as they do not 
interfere with each other, we can still use equivalences to usefully manipulate them. For 
example, if h' is a handler with no operation case for £#lookup then 

77[(with h' handle £#lookup () ( y . c)), e] 

= %[(£#lookup O ( y . with h! handle c)), e] 

= 77[(with h' handle c[e/y]), e]. 

It may happen that a lookup or an update is nested deeply inside several handlers. The 
above transformation allows us to hoist the operation out of the inner handlers so that it 
is handled by the outer handler, as long as the inner handlers do not attempt to handle l. 
The transformation applies to let bindings too, as they are like handlers without operation 


cases. 
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We may validate the seven standard equations governing state [16]. There are four 
combinations of lookup and update (in the first equation y does not occur free in c): 

77[t#lookup () (y. <,#update y (_ . c)), e] = 'H[c,e\ 

"H[i#lookup C) (y. t#lookup () (z. c)), e] = 77[i#lookup O (y. c[y/z]), e] 

Ti [t#updat e e (_ . i # updat e e' (_ . c) ) , e] = 77 [z#updat e e / (_ . c) , e] 

?7[/#update e (_ . /.#lookup () (y. c)), e] = 77[r#update e (_ . c[e/y]), e] 

For instance, the first equation is validated as follows: 

"H[/#lookup O (y. i#updatey (_ . c)), e] 

= ?^[t#update e (_ . c), e] 

= 77 [c, e] 

Three more equations describe commutativity of lookups and updates at different distances. 
Let L\ ^ L 2 , and write 77i and 77 2 for the the abbreviation 77 with respect to b\ and 12 , 
respectively: 

'Hi[H 2 [ii#lookup O (yi. t 2 #lookup () (y 2 . c)), e 2 ], ei] 

= 77i[77 2 [t 2 #lookup O (y 2 . ti#lookup () (yi. c)), e 2 ], ei] 
'Hi[?^ 2 [ii#update ei (_ . i 2 #updatee 2 (_ . c)), e 2 ], ei] 

= 77i[77 2 [r 2 #update e 2 (_ . ii#updateei (_ . c)), e 2 ], ei] 

77 1 [77 2 [ii#update e (_ . i 2 #lookup C) (y 2 - c)), e 2 ], ei] 

= 77i[77 2 [t 2 #lookup C) (y 2 .ti#updatee(_.c)),e 2 ],ei] 

Let us check the last equation. The left-hand side transforms as 
77i[77 2 [ti#update e (_ . i 2 #lookup () (y 2 . c)), e 2 ], ei] 

= 77i[ii#update e (_ . 77 2 [p2#lookup C) (y 2 . c), e 2 ]), ei] 

= 77i[77 2 [i 2 #lookup O (y 2 . c), e 2 ], e] 

= 77i[77 2 [c[e 2 /y 2 ], e 2 ], e] 

and the right-hand side as 

77 1 [H 2 [t 2 #lookup C) (y 2 .ii#updatee(_.c)),e 2 ],ei] 

= 77i[77 2 [ii#updatee (_ . c[e 2 /y 2 ]), e 2 ], e 1 ] 

= 77i[/n#update e (_ . 77 2 [c[e 2 /y 2 ], e 2 ]), ei] 

= 77i[77 2 [c[e 2 /y 2 ], e 2 ], e]. 

The remaining two equations are proved much the same way. The symmetry in the equations 
also shows that it does not matter in which order we nest the handlers for l\ and t 2 . 

7.2. Commutativity of non-interfering computations. Swapping lookups and up- 
dates that act on different instances is only a basic reasoning step. In practice we want 
to swap whole computations, as long as they do not interfere. To make the idea precise, let 
Ai = {ii#lookup, ii#update}, A 2 = {t 2 #lookup, i 2 #update}, let ci and c 2 be computations 
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of types A\ ! Ai and A 2 ! A 2 , respectively, and c a computation of type C in the context 
xi : Ai,X 2 : A 2 . We would like to show the equivalence 

77i[77 2 [let xi = ci in (let x 2 = c 2 in c),e 2 ],ei] 

= 77i[77 2 [let x 2 = c 2 in (let x\ = c\ in c),e 2 ],ei]. 

This is a commutativity law which allows us to transpose, or run in parallel, any computa- 
tions that use only non- interfering references. 

First, let us establish a simpler equivalence, which we are going to use in the proof: 

77i[77 2 [ii#lookup 0 (y ] . let x 2 = c 2 in (let x\ = c[ in c)), e 2 ], ei] 

= 77i[77 2 [let X 2 = c 2 in (let x\ = ii#lookup () (yi. c\ ) in c), e 2 ], e 1 ] 

We proceed by induction on c 2 . Since handlers and let are strict, both sides are _L when 
we set c 2 to _L. Next, if c 2 is val e 2 , the two sides are equal already without handlers: 

ii#lookup O {y\. let x 2 = val e 2 in (let x± = c^ in c)) 

= ii#lookup O (y\. let x\ = in c[e 2 /:r 2 ]) 

= ii#lookup O (y 1 . let x± = c\ in (let x 2 = val e 2 in c)) 

= let x\ = ri#lookup () (y\. C\ ) in (let x 2 = val e 2 in c) 

For the induction step, suppose c 2 is a call of / 2 #update (the case lookup is similar): 
%i[% 2 [M#lookup O (yi. let x 2 = t 2 #update e ' 2 (z. kz ) in (let x\ = c\ in c)), e 2 ], e±] 

= "Hi[ii#lookup O (yi. "% 2 [let x 2 = k() in (let x\ = c) in c),e' 2 ]),e 1 ] 

= "Hi['H 2 [ii#lookup O (yi. let x 2 = «:() in (let xi = in c)),e' 2 ],e 1 ] 

= - Hi[H 2 [let x 2 = ftO in (let xi = ii#lookup O (yi. c^) in c), e' 2 ], ei] 

= [7^2 [let x 2 = t 2 #update e ' 2 (z. kz) in (let x\ = ii#lookup O (y±. c \ ) in c), e 2 ], ei] . 

In the third step we used the induction hypothesis for k(). 

We now prove the main statement by induction on c\. When c\ is 1 or a value, the 
statement is easy. If c\ is a call of ii#lookup, we have: 

77i[77 2 [let x\ = ti#lookup O (yi- Kyi) in (let x 2 = c 2 in c), e 2 ], e{\ 

= 77i[ii#lookup O (yi. 77 2 [let xi = Kyi in (let x 2 = c 2 in c), e 2 )], ei] 

= 77i[77 2 [let xi = nei in (let x 2 = c 2 in c),e 2 ],ei] 

= 77i[77 2 [let X 2 = c 2 in (let x\ = Ke 1 in c), e 2 ], ei] 

where in the last step, we used the induction hypothesis for Ke±. The last line is equivalent 
to the other side of the desired equivalence: 

77i[77 2 [let x 2 = c 2 in (let x± = nei in c), e 2 ], e\] 

= 77i[ri#lookup O (yi.77 2 [let x 2 = c 2 in (let x\ = Kyi in c),e 2 ]),ei] 

= 77i[77 2 [let x 2 = c 2 in (let x\ = i-i#lookup O (yi- Kyi) in c),e 2 ],ei]. 

The proof for update is similar. 
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8. Formalization in Twelf 

We formalized core Eff , the effect system and the safety theorems in Twelf. The files 
are enclosed with this paper, or can be found at the GitHub repository [3]. The code is 
compatible with Twelf version 1.7.1. Further instructions and description of the code can 
be found in the file README . md. 


9. Discussion 

The only essential feature of Eff that is missing from core Eff is dynamic creation of 
instances with the new E construct. We omitted it because it leads to significant complica- 
tions, both in the effect system and in semantics. One possible treatment of new would be 
to upgrade the current setup with nominal logic and nominal domain theory. 

Non-termination is a computational effect which is not reflected in our effect system. 
It would be interesting to add a “divergence” effect. Such an effect would originate from 
applications of recursive functions. However, since divergence cannot be handled it would 
never disappear from effect information, and would likely become an uninformative nuisance. 
A potential remedy would be to separate general recursive definitions, which may diverge, 
from structural recursive definitions, which always terminate. 

A realistic implementation of our effect system would only be useful if it actually inferred 
computational effects. Such a possibility was explored by the second author [22], and an 
early prototype is available in the latest implementation of Eff [5]. 

Acknowledgment. We thank the anonymous referees for useful suggestions and a lesson 
in domain theory. 
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